Platform engineering is the method and discipline of designing and building platforms that enable self-service capabilities for teams, and increasingly AI agents, to automate the recurring aspects of knowledge work.
The discipline is practiced by dedicated platform teams who design, build and run these platforms as internal products. In software organizations the platform is known as an Internal Developer Platform (IDP): a set of paved paths that give developers self-service access to everything they need - environments, deployments, security scans - without tickets or tribal knowledge.
A platform is not a tool, a portal, or a dashboard, but the sum of paths enabled by a set of capabilities, exposed through interfaces. Paths help internal users to get things frictionlessly from other parts of the organization that they need to achieve an outcome.
.png)
The job function responsible for the platform is called the platform engineer. It’s a platform engineer's job to design and build platforms of all shapes, continuously refine them and treat them as a product in themselves.
The discipline originates in software development, where most enterprises now have dedicated platform teams. Platform engineering teams in software organizations are responsible for building Internal Developer Platforms (IDPs). These platforms are used to standardize and automate the work of hundreds or thousands of software engineers and do the undifferentiated heavy lifting for them. As an increasing share of agents enter the scene, platform engineering teams are starting to build Agentic Development Platforms (ADPs).
An Agentic Development Platform is a platform built and operated by the platform engineering team that enables collaborative software development between engineers and AI agents. ADPs build upon the five planes of an Internal Developer Platform yet also include the infrastructure required to run and coordinate agents (Agent Infrastructure) as well as Path Specifications, i.e. maps for agents to find their way around the platform. In some organizations the underlying agent infrastructure provided by the platform teams is used to power agentic workflows across other vertical business functions. ADPs therefore evolve into AxPs, e.g. Agentic Legal or Marketing Platforms, which are all running on the same Agent Infrastructure substrate.
The demand for AI and agentic use cases in the enterprise is therefore turning platform engineers into one of the most pivotal roles in organizations today. A well-designed platform foundation and established platform engineering practice increasingly make the difference between top-performing companies and their competition falling behind, as the industry accelerates towards the agentic enterprise.
Why platform engineering exists
Skilled people do their best work when there is a well-designed system in place for what they do. Without one, every recurring task becomes a small act of improvisation: environments assembled by hand, deployment knowledge living in the heads of a few senior engineers, every team solving the same problem slightly differently. Organizations inherently choose a system of “producing” knowledge work. We differentiate four production systems of knowledge work: hero-based (concentrated expertise in knowledge silos), artisanal (informal coordination with diffused responsibilities), bureaucratic (prescribed processes with fragmented ownership) and platform-based (provides deliberate design, explicit interfaces and continuous improvement of a product).
Platform-based production systems are deliberately different. The idea is to introduce a product - the platform - as a contract between different parties to achieve a certain task. The handover point is consistently refined and designed as explicit interfaces. The platform has users, and the entire point is to take the repetitive burden off them so they can focus on judgment, craft, and decision-making.
What is a platform?
A platform is not a single tool you can point to. A good way to understand what a platform is is to think about a setup without one. If you are a software developer working in an organization that has not built an Internal Developer Platform (IDP) and you need an ephemeral environment, a database or a security scan you would have to either upskill yourself and solve the problem on your own or ask a colleague in a separate team for help or support. Both options lead to friction and make the resulting estate hard to maintain in the long run. If the organization has an IDP, the software developer has a structured way to request these repeated necessities from the platform. The platform would for instance expose an interface through which the developer could request an ephemeral environment of a given type and the platform would automatically create and service it.
A way of thinking about a platform is as a collection of paths, queued alongside a value stream, that lead to outcomes for the business. In our software example the path would be “how to get an ephemeral environment” and the value stream would be “developing a new feature” whereas the business outcome would be “happy users that buy more products”.
The idea of the path is one of the most important concepts in platform engineering. Also referred to as “golden path” or “paved road”, has been shaped by many practitioners, notably at Netflix and Spotify, and articulated well by Charity Majors. The idea is to provide teams with a supported, opinionated route through recurring work that is faster than doing it manually and safer than avoiding it. The platform makes the right way the easy way. Standards, guardrails, and institutional knowledge are baked into the path itself rather than living in the heads of a few senior colleagues.
Every path is consumed through one or several different interfaces that should be embedded into the user's workflow. They expose the underlying capability of the path which is usually abstracted from the user for convenience and to drive standardization. The actual tools used within the platform are part of those capabilities but might change over time.
Platforms are products and should be treated as such. This implies that a platform serves users from which the platform team should gather feedback to improve the product. It means that the platform isn’t a short-term fix but a long-term living thing that requires constant maintenance and iteration.
The variety of paths knowledge workers demand to streamlining recurring tasks differs wildly by vertical and organization and so does the shape and form of the respective platform.
The history of platform engineering: from DevOps to IDPs
In the late 1990s and early 2000s, operations ran on the SysAdmin model: developers wrote code and threw it over the fence to the people who ran the systems. It was slow, it created gatekeepers, and it could not survive the cloud. When AWS launched in 2006, infrastructure became something you could program, and the fence had to come down. DevOps emerged as the answer: "you build it, you run it."
Except that's not how things turned out in most organizations. Research on engineering performance consistently showed the pattern that low-performing organizations live with the shadow operations antipattern, where some developers end up doing DevOps tasks on their own and helping their less experienced colleagues. The promise of DevOps quietly turned a few senior engineers into an unofficial help desk. Meanwhile, a small set of top-performing organizations got "you build it, you run it" to actually work. The difference was that top performers built an internal platform that made self-service possible, with dedicated teams treating it as a product.
That platform became known as the Internal Developer Platform, a term coined by Kaspar von Grünberg in 2020. One early definition described it as "the sum of all the tech and tools that a platform engineering team binds together to pave golden paths for developers."
This definition built on top of the original framework by Team Topologies, which gave the organizational pattern a name and a place: the platform team. One of four fundamental team types alongside stream-aligned, enabling, and complicated subsystem teams, existing to reduce the cognitive load of the teams that ship products. By 2021, Platform Engineer as a job title was mainstream, and platform engineering became one of the fastest-growing disciplines in IT. Today, our community of more than 280,000 platform engineers live and breathe the discipline every day.
From here platform engineering quickly expanded to all parts of the IT organization. Early platform teams primarily originated from infrastructure and DevEx groups. With the scope of platforms expanding, it became clear that surrounding specialized teams should roll into the platform team in order to optimally embed all capabilities into the platforms. This marked the rise of specialized platform engineering functions such as security platform engineering, reliability platform engineering, platform product manager and dedicated management functions such as the head of platform engineering. Today, platforms at top performing organizations are where security, compliance, FinOps and reliability are embedded by design in one unified layer and user experience.
The AI transformation is appearing to create an inflection point for the platform engineering discipline as teams that have previously built platforms for software developers are increasingly asked to build platforms of varying types for agents. This creates job security and a surge in demand for the role. It will remain to be seen how this plays out.
Platform engineering principles and how to get started
The operating principles of good platform teams have not changed, and they apply to agentic platforms exactly as they applied to Internal Developer Platforms:
- Clear mission and role: A platform team is a dedicated product unit, not a helpdesk.
- Treat your platform as a product: Driven by user feedback, not technology trends. Everything else rests on this.
- Start with a small Minimum Viable Platform (MVP): A small scope of a few paths to get started.
- Focus on common problems: Solve the shared pain points teams keep solving in isolation.
- Talk to your users: Your users are the core focus, you’re building for them, so talk to them!
On timing, the old rule of thumb still works: once an organization grows past 20 to 30 platform users, the coordination cost of doing everything by hand stops being manageable, and a platform starts paying for itself. With agents in the mix, the threshold arrives earlier because agents multiply the volume of work moving through your paths.
On approach, most platform initiatives that fail do so the same way: they start too big, build for too long without testing, and optimize for stakeholder narratives instead of user adoption. The alternative is a playbook built on one principle: start small and learn fast, then scale deliberately. Begin with a Minimum Viable Platform built around a small number of high-value paths. Make that subset production-ready before you grow it, and only then scale paths, teams, and organizational integrations. Throughout all of it, one practice stays central: talk to your users continuously. That now includes agents. Agents are revealing users: they expose every gap, ambiguity and undocumented assumption in your paths, because unlike humans they can't fall back on tribal knowledge. That’s where the need for even more user centric and well designed platforms is core in the evolution of this discipline.
Platform engineering has already reshaped how major enterprises build software. It is now becoming the methodology for running agents at scale, making it one of the most future-proof disciplines in tech. Join more than 280,000 practitioners in the world's largest platform engineering community, and go deeper in Thinking in Platforms.
Note: The first version of this blog post was published on 20 June 2021 and it was last updated on 18 August 2026.
